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ABSTRACT 

Symbolic  evaluation  is  a process  which  abstractly  evaluates  an  program  on 
abstract  data.  A formalism  based  on  conceptual  representations  is  proposed  as  a 
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specifications  and  specifications  based  on  conceptual  representations  are  discussed  and 
limitations  of  the  current  algebraic  specification  techniques  are  pointed  out.  Symbolic 
evaluation  is  carried  out  with  explicit  use  of  a notion  of  situations.  Uses  of 
situational  tags  in  assertions  make  it  possible  to  state  relations  about  properties  of 
objects  in  different  situations.  The  proposed  formalism  can  deal  with  problems  of 
side-effects  which  have  been  beyond  the  scope  of  Floyd-Hoare  proof  rules  and  give  a 
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I.  INTRODUCTION 


Our  goal  is  to  construct  a software  system  called  a Programming  Apprentice 
[Hewitt  & Smith  1975)  which  aids  expert  programmers  in  various  aspects  of  programming 
activities,  such  as  verification,  debugging  and  refinement  of  programs.  As  its  major 
component,  the  Programming  Apprentice  has  a very  high  level  interpreter  which  abstractly 
evaluates  a program  on  abstract  data  and  tries  to  see  whether  the  program  satisfies  its 
contracts  (specifications).  We  call  this  process  ’symbolic  evaluation ’ [Hewitt  et  al  1973, 
Boyer  & More  1975,  Burstall  Sc  Darlington  1975.  Rich  & Shrobe  1975,  Yonezawa  1975.  King 
1976).  The  main  purpose  of  symbolic  evaluation  is  not  simply  to  verify  that  implementations 
meet  their  specification.  Rather  the  purpose  is  to  provide  sufficient  information  for 
answering  questions  about  dependencies  between  program  modules  in  order  to  understand 
implications  of  the  proposed  changes  in  both  specifications  and  implementations.  To 
accomplish  these  purposes,  symbolic  evaluation  must  be  based  on  an  adequate  coherent 
formalism  which  consists  of: 

1)  a formal  language  for  writing  specifications  of  modules  (procedures  or  data  structures) 

which  may  change  their  behavior  (side-effects)  [Burstall  1972.  Creif  8c  Hewitt  1975, 

Yonezawa  1975], 

2)  a formal  system  for  reasoning  in  situations  where  side-effects  are  involved,  and 

3)  a formal  language  for  expressing  commentary  about  modules. 

Since  the  Programming  Apprentice  should  provide  an  environment  where 
programmers  can  easily  communicate  and  cooperate  with  the  system  in  an  interactive 
manner,  it  is  equally  important  that  the  formalism  used  in  the  Programming  Apprentice 
should  be  intuitively  clear  and  easily  understood  by  programmers.  This  paper  describes  a 
formalism  which  attempts  to  meet  these  requirements. 

Our  research  is  closely  related  to  the  research  on  program  verification  systems. 
Previous  program  verification  systems[Kmg  1969,  Deutch  1973,  Igarashi  London  Sc  Luckham 
1973,  Suzuki  1974,  Boyer  Sc  Moore  1975,  Cood  London  Sc  Bledsoe  1975,  King  1976]  have  been 
limited  in  their  ability  to  deal  with  programs  which  change  their  behavior  (side-effects) 
because  of  the  inadequacy  of  the  formal  systems  on  which  these  implementations  were 
based.  Furthermore,  previous  research  on  algebraic  and  axiomatic  techniques  [Hoare  1972, 
Spitzen  Sc  Wegbreit  1975,  Zilles  1975.  Guttag  1976,  Wegbreit  Sc  Spitzen  1976]  for  specifying 
data-structures  has  concentrated  on  data-structures  without  side-effects.  Although  a 
program  with  side-effects  can  sometimes  be  transformed  into  a program  without  side-effects 
[Greif  Sc  Hewitt  1975],  the  transformation  decreases  efficiency  and  requires  more  storage. 
Also  there  is  a certain  type  of  side-effect  in  communication  between  concurrent  processes 
which  is  impossible  to  realize  without  side-effects.  In  the  early  sections  of  this  paper,  we  will 
present  a new  formalism  which  can  deal  with  side-effects  and  discuss  limitations  of  previous 
work  on  program  verification  and  algebraic  (or  axiomatic)  specification  techniques.  Then 


3 


in  the  later  sections,  we  will  illustrate  how  the  symbolic  evaluation  is  carried  in  our 
formalism. 


2.  CONCEPTUAL  REPRESENTATIONS 


In  this  section  we  introduce  the  idea  of  conceptual  representations  as  an  important 
part  of  our  specification  language.  Conceptual  representations  can  be  used  for  specifying  a 
wide  range  of  data  structures  at  various  levels  of  abstraction[Liskov  & Zilles  1975).  The 
basic  motivation  of  conceptual  representations  is  to  aid  in  providing  a specification 
language  which  serves  as  a good  interface  between  programmers  and  the  computer  and  also 
between  users  and  implementors.  A “good"  interface  language  should  allow  programmers  to 
easily  express  and  understand  their  intuitive  concept  of  a data  structure  and  how  it  behaves 
for  various  operations.  In  this  sense  the  "language"  of  diagrams  using  boxes  and  arrows  is 
a very  good  language  in  which  people  can  exchange  their  intuitive  ideas,  but  it  is  not 
rigourous  and  unambiguous  enough  for  the  computer  to  understand  without  many  hidden 
assumptions.  Conceptual  representations  can  be  viewed  as  a language  which  can  express 
graphical  specifications  of  data  structures.  Different  degrees  of  awareness  about  the 
implementation  of  a data  structure  are  required  in  the  different  activities  of  implementing  a 
system  such  as  the  initial  design,  coding,  and  the  subsequent  evolution.  Conceptual 
representations  should  be  flexible  enough  to  express  Just  the  details  that  are  important  in 
each  activities.  In  this  section  we  give  a simple  example  of  the  use  of  conceptual 
representations. 

Consider  queues  as  an  illustrative  example.  Programmers  envisage  a queue  a 
linear  sequence  of  elements  which  are  enqueued  at  one  end  and  dequeued  at  the  other  end. 
Suppose  we  have  a queue  consisting  three  elements,  a,  b,  and  c.  where  a is  its  front  element 
and  c is  its  last  element.  We  can  use  the  following  notation  for  the  conceptual 
representation  of  this  queue. 

(QUEUE  a b c) 

To  express  a queue  which  has  an  Indefinite  number  (including  zero)  of  elements,  the 
notation: 

(i QUEUE  !x) 

is  used  where  |x  is  an  abbreviation  of  the  "unpack"  operation  on  x whose  result  is 
equivalent  to  writing  out  all  of  elements  denoted  by  x individually.  For  example,  if  x 
denotes  a sequence  [b  c d],  then  the  sequence  [a  Jx]  is  equivalent  to  [a  b c d]  whereas  the 
sequence  [a  x)  is  equivalent  to  (a  [b  c dj]  Thus  ( QUEUE  »x)  is  equivalent  to  ( QUEUE  b c d). 
If  y denotes  an  empty  sequence  [},  then  I QUEUE  !y)  is  equivalent  to  (QUEUE  ) which  is  the 
conceptual  representation  of  an  empty  queue  More  elaborate  example  are 


(QUEUE  • !z)  and  QUEUE  U b) 

which  are  the  conceptual  representations  of  queues  with  a as  its  front  element  and  with  b as 
its  last  element,  respectively. 

A complete  specification  of  queues  is  given  by  describing  how  a queue  is  created 
and  how  it  behaves  when  certain  legitimate  operations  are  applied.  First,  we  specify  the 
domains  and  ranges  of  the  operations: 

fl.  create -queue:  --->  queue 

12.  enqueue:  queue  x item  — > queue 

13.  dequeue:  queue  > item  x queue  or  error 

14.  ia-empty:  queue  > boolean 

The  following  is  a formal  specification  of  queues  using  the  conceptual  representations. 
cl.  create*queue()  = (QUEUE  ) 
c2.  onqumuo((QUEUE  !x),  A)  = (QUEUE  !x  A) 
c3.  dequeu o((QUF.UE  ))  a ERROR:  attempt-lo-dequeue-empty-queue 
c4.  dequeue ( (QUEUE  A !x»  = <A  , (QUEUE  !x)> 
c5.  it-empl y((QUF.UE  ))  = true 
e6.  is-ompty  ((QUEUE  A !x))  = falte 

Previous  investigators  have  used  algebraic  and  axiomatic  techniques  for  the 
formal  specifications  of  data  structures  [Hoare  1972,  Sptizen  & Wegbreit  1975,  Zilles  1975, 
Cuttag  1976,  Wegbreit  & Spitzen  19761  To  compare  it  with  our  approach,  we  present  an 
algebraic  specification  of  queues. 


al.  i*-empty(create-queue())  = true 
a2.  ie-empty (enqueuefq,  A))  a fatte 

a3.  dequeue(create-queueO)  a ERROR:  atlempl-to-dequeue-empty-queue 

a4.  if  it-empty(q)  then  dequeue(enqueue(q,  A))  z <A,  q> 

a5.  if  -4»-empty(q)  a dequeue(q)  a <B,  q'> 

then  dequeue(enqueue(q,  A))  a <B,  enqueuetq',  A)> 


The  above  axioms  are  easily  derived  from  our  specification  of  queues  based  on  conceptual 
representations.  (For  the  derivation  of  the  axiom  a5,  see  Appendix  I.)  We  believe  that 
specifications  using  conceptual  representations  are  often  easier  for  programmers  to  both 
write  and  understand  than  algebraic  or  axiomatic  specifications.  Because  the  conceptual 
representation  approach  directly  describes  what  effects  take  place  in  data  structures  (at  the 
conceptual  level)  when  the  operations  are  applied,  whereas  the  algebraic  and  axiomatic 
specifications  describes  the  effects  of  the  operations  indirectly  in  terms  of  relations  (or 
equations)  among  the  operations  as  illustrated  in  the  above  axioms  al  to  a5.  Such  indirect 
specifications  are  often  difficult  to  grasp.  Thus  the  author  or  reader  of  such  an  indirect 
specification  of  a data  type  D tends  to  be  less  confident  whether  or  not  the  specification 
completely  describes  the  desired  properties  of  the  data  type  D.  Furthermore  the  current 
algebraic  and  axiomatic  techniques  do  not  capture  an  important  difference  between  data 
structures  without  side-effects  and  data  structures  with  side-effects.  (This  difference  will  be 
explained  in  Section  3 and  Section  4.)  As  we  will  see  in  Section  6,  the  specification  technique 
using  conceptual  representations  can  easily  capture  this  difference. 

Besides  queues  discussed  above,  conceptual  representations  of  other  simple  data 
structure  such  as  cells  and  sequences  will  be  used  in  this  paper.  More  detailed  discussions 
and  examples  of  the  conceptual  representations  of  more  complicated  data  structures  such  as 
sets,  bags,  arrays,  lists,  symbol  tables,  file  directories  e.t.c.  will  be  found  in  [Yonezawa  19771 


3.  ACTORS.  PURE  AND  IMPURE 


Since  our  symbolic  evaluation  is  based  on  the  actor  model  of  computation  [Hewitt 
and  Baker  1976,  Creif  Sc  Hewitt  1975],  we  will  begin  with  a brief  explanation  of  actors. 

An  actor  is  a potentially  active  piece  of  knowledge  (procedure)  which  is  activated 
when  it  is  sent  a message  by  another  actor.  Actors  interact  by  sending  messages  to  other 
actors.  Each  actor  decides  itself  how  to  respond  to  messages  sent  to  it.  An  actor  is  defined 
by  its  two  parts,  script  and  acquaintances  Its  script  is  a description  of  how  it  should 
behave  when  it  is  sent  a message.  Its  acquaintances  are  a finite  set  of  actors  that  it  directly 
knotas  about.  If  an  actor  A directly  knows  about  another  actor  B.  A can  directly  send  a 
message  to  B.  The  behavior  of  an  actor  can  be  roughly  characterized  by  stimuli  (messages  as 
data  and  questions)  and  responses  (messages  as  answers).  In  the  actor  paradigm,  the 
traditional  concepts  of  procedure  and  data-structure  are  unified.  Furthermore  various  kinds 
of  control  structures  such  as  go-to’s,  procedure  calls,  and  coroutines  can  be  viewed  as 
particular  patterns  of  message  passing  [Hewitt  1976a]  Thus  a complete  model  of 
computation  can  be  constructed  with  a system  of  actors.  An  implementation  of  this  model  is 
realized  as  a programming  language  PLASM  A[Hewitt  1976b]. 

All  actors  are  classified  into  two  categories  depending  upon  their  behavior.  Actors 
which  belong  to  one  category  never  change  their  behavior.  They  are  called  pure  actors. 
Actors  which  belong  to  the  other  category  are  called  impure  actors  and  their  behavior 
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may  change  with  time.  More  precise  definitions  are  as  follows. 

An  actor  is  pure  if  it  always  gives  the  same  response  to  the  same  message. 

An  actor  is  impure  (not  pure)  if  it  does  not  always  give  the  same  response  to  the 

same  message. 

From  this  definition,  it  can  be  said  that  a pure  actor  behaves  like  a mathematical  function. 
The  only  primitive  impure  actor  we  will  use  is  the  "cell".  A cell-actor  accepts  a message 
[update:  v)  which  updates  its  contents  and  a message  [content*?)  which  retrieves  its  contents. 
A cell-actor  may  change  its  behavior  because  it  can  give  different  answers  to  the  [content*?) 
message,  depending  upon  what  it  contains  at  the  moment.  An  example  of  a pure  actor  is  a 
sequence-actor.  One  can  retrieve  elements  of  a sequence-actor,  but  cannot  change  its 
elements;  instead  a completely  new  sequence-actor  must  be  created.  So  a sequence-actor  is 
pure.  The  notion  of  impureness  of  actors  is  closely  related  to  that  of  side-effects  in  the 
traditional  programming  languages.  A typical  example  of  "side-effects"  is  the  effect  of 
updating  components  of  a shared  record.  This  type  of  side-effect  can  be  viewed  as  the 
change  of  behavior  of  actors  which  behave  like  data-structures.  Cells  do  not  make  serious 
trouble  for  program  verification  if  sharing  is  not  involved.  But  as  will  be  seen  in  Section  5, 
serious  problems  arise  when  impure  actors  which  behave  like  data  structures  are  shared 
between  actors. 


i PURE  QUEUES  AND  IMPURE  QUEUES 


In  this  section,  we  introduce  a pure  actor  and  an  impure  actor,  both  of  which 
behave  like  a queue.  Using  them  as  an  illustrative  example  we  discuss  the  problems  of 
previous  work  on  program  verification  systems  and  formal  specification  techniques  in 
dealing  with  side-effects,  (cf.  Section  5) 

Both  pure  queue-actors  and  impure  queue-actors  accept  the  same  two  kinds  of 
messages,  one  is  [nq:  x)  which  is  a request  to  enqueue  a new  elements  x,  and  the  other  is 
(dq:)  which  is  a request  to  take  out  the  front  element  of  the  queue  and  return  it  with  the 
remaining  queue.  However  if  the  queue  is  empty,  it  returns  a complaint  message 
[exhau*ted:).  The  important  difference  between  a pure  queue-actor  and  an  impure 
queue-actor  is  whether  or  not  a new  queue-ictor  is  created  when  [nq:  ...I  and  [dq:)  are  sent. 
When  [nq:  x)  is  sent  to  a pure  queue-actor  PQ  a new  pure  queue-actor  PQ’  which  has  x as 
the  last  element  of  the  queue  is  created  and  returned  The  original  queue-actor  PQ  still  has 
the  same  elements  as  before.  When  [nq:  x)  is  sent  to  an  impure  queue-actor  IQ,  x is 
absorbed  inside  IQ  and  enqueued  at  rear  of  the  previous  elements.  So  IQ  itself  is  extended 
and  returned.  No  new  queue-actors  are  created.  (See  Figure  I.)  When  [dq:)  is  sent  to  a pure 
queue-actor  PQ  (which  is  not  empty),  a new  pure  queue-actor  PQ’  whose  elements  are  all 
elements  of  PQ  except  the  front  element  of  PQis  created  and  the  front  element  of  PQand 
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the  new  pure  queue-actor  PQ  are  returned.  Again  the  original  PQ  is  intact  and  has  the 
same  elements  as  before.  When  (</7.)  is  sent  to  IQ  (which  is  not  empty),  thpn  the  front 
element  of  IQ  and  IQ  itself  which  now  has  the  rest  of  the  original  elements  are  returned. 
No  queue-actors  are  created. 

It  might  be  helpful  to  see  LISP  analogy  in  understanding  this  difference  between 
pure  queues  and  impure  queues.  Suppose  that  a queue  is  implemented  as  a list  L.  Then 
sending  (n7:  x)  to  a pure  queue-actor  corresponds  to  (append  L (list  x))  whose  result  is  a 
totally  new  list  constructed  from  a copy  of  L and  x and  sending  (n7:  x)  to  an  impure 
queue-actor  corresponds  to  (nconc  L (list  x))  whose  result  does  not  consist  of  a copy  of  L. 


abed 


Figure  1 


The  two  formal  specifications  of  queues  in  Section  2.  one  based  on  the  conceptual 
representations  and  the  other  by  algebraic  specifications,  do  not  distinguish  the  above 
important  difference  between  impure  queues  and  pure  queues.  In  Section  6 by  slightly 
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extending  the  interpretation  of  the  conceptual  representations,  we  will  give  a specification  of 
queues  which  captures  this  distinction. 

5.  SITUATIONS  AND  SIDE-EFFECTS 


In  order  to  deal  with  behavior  that  changes  with  time,  we  need  a powerful 
coherent  formalism  for  specifications  and  reasoning.  A general  technique  we  employ  to  cope 
with  this  kind  of  problems  is  to  explicitly  introduce  a notion  of  st  tug  trorr[McCarthy  & 
Hayes  1969]  into  the  formalism. 

A situation  is  the  local  state  of  an  actor  system  at  a given  moment.  (If  an  actor 
system  has  no  concurrency,  there  is  no  distinction  between  the  local  states  and  the  global 
states  of  the  actor  system.)  For  example,  the  contents  of  a cell-actor  C changes  from  time  to 
time  according  to  the  update  messages  which  have  been  most  recently  sent  to  C.  Suppose  that 
in  a situation  S the  contents  of  C is  3 and  that  C receives  ( update : 4)  message  in  S.  Then  in 
the  situation  S’  after  C receives  the  message,  the  contents  of  C is  4.  (See  Figure  2.) 
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By  using  a symbol  S to  denote  a situation,  we  cart  refer  to  the  contents  of  C in  the  situation 
in  the  following  manner: 

(content*  C)  in  S. 

We  call  a symbol  such  as  S,  which  is  used  to  refer  to  a situation,  a sttuationot  toy  In 
the  later  sections,  we  will  see  how  the  notion  of  situations  is  used  in  writing  specifications  of 
modules  (Section  6)  and  in  carrying  out  symbolic  evaluation  (Section  8,  10  and  12)  where 
side-effects  are  involved.  In  the  rest  of  this  section  we  restrict  ourselves  to  giving  simple 
examples  of  how  the  notion  of  situations  is  introduced  into  our  formalism 

The  previous  work  on  formal  proof  rules  and  program  verification  systemstKing 
1969,  Deutch  1973,  Igarashi  London  & Luckham  1973,  Suzuki  1974,  Boyer  Sc  Mocre  1975,  Good 
London  & Bledsoe  1975]  has  difficulties  in  dealing  with  the  problems  of  side-effects  To 
illustrate  such  difficulties,  let  us  consider  the  following  piece  of  PLASMA  program 

(/el  (queue-1  = (create-queue))  ;nn  empty  queue  it  created  and  bound  to  queue-1 

then 

(let  (queue-2  = (create-queue))  ;an  empty  queue  it  created  and  hound  to  queue-2 

(hen 

(/el  (queue-3  = (queue-1  <=  (nq.  2))) 

;(nq:  2)  i«  lent  to  queue-1  (i.e.  2 i*  enqueued  at  rear  of  queue-1) 

;and  the  renult  is  hound  to  queue-3 

then 

(queue-1  <=  (nq:  3))  (nq:  3)  it  tent  to  queue-1  (i.e.  3 is  enqueued  at  rear  of  queue-1.) 


. ))) 

Suppose  that  a verification  system  is  asked  whether  or  not  the  length  of  queue-1  is  equal  to 
that  of  queue-3  after  the  last  statement.  A usual  way  of  answering  this  question  is  to  find 
out  which  queue-actor  queue-1  and  queue-3  refer  to  and  get  the  length  of  each  queue  and 
then  compare  each  length.  To  do  so,  the  system  has  to  know  at  least  the  following  things: 

1)  what  kind  of  queue-actors  are  created  (e  g pure  or  impure), 

2)  whether  or  not  and  how  queue-actors  are  shared  and 

3)  which  queue-actors  are  affected  by  each  event  (i.e.  message  passing) 

Our  formalism  that  uses  the  notion  of  situations  can  easily  deal  with  this  kind  of 
problem.  Let  SpoJt  denote  the  situation  after  the  last  statement  in  the  above  code  is 
executed.  The  question  whether  or  not  the  length  of  queue-1  is  equal  to  that  of  queue-3  in 
that  situation  is  stated  as  follows: 

((length  queue-1)  it-equnl  ( length  queue-3))  in  Spoj|. 


10 


By  distributing  the  situational  tag  Spojj.  the  same  question  can  be  stated  in  the  following 
two  different  manners: 

([length  queue-1)  in  S ,)  is-equal  ((length  queue-3)  in  S .)  or 

post  post 

(length  (queue-1  in  S .))  it~equal  (length  (queue-3  in  S )) 

post  ■ post 

Since  situational  tags  allow  us  to  relativize  facts,  relations  between  facts  holding  in  different 
situations  can  be  easily  stated  in  our  formalism  For  example,  an  assertion  that  the  length  of 
queue-1  in  Sppst  is  greater  than  the  length  of  queue-1  in  the  situation  Sprp  before  the  last 
statement  is  executed  is  stated  as: 

(( length  queue-1)  in  S ,)  it-greater  ((length  queue-1)  in  S ) 

post  pro 

This  kind  of  assertion  is  quite  useful  to  show  the  termination  of  programs[Yonezawa  19751 
Furthermore  a question  about  the  identity  of  the  queues  is  easily  stated  as: 

(queue-1  in  Spol,)  it-eq  (queue-3  in  Sprp) 


We  will  see  how  our  reasoning  system  deals  with  these  statements  in  the  later 

sections. 


6.  CONTRACTS  FOR  IMPURE  QUEUES  AND  PURE  QUEUES 


In  this  section  we  will  illustrate  how  contracts  for  impure  queues  and  pure  queue 
can  be  expressed  in  our  formalism  based  upon  the  conceptual  representations.  We  use  the 
term  "contract"  instead  of  "specification"  to  emphasize  the  fact  that  it  is  an  agreement  or  a 
"treaty"  between  implementors  of  a module  and  its  users  Users  of  a module  M should  only 
rely  on  properties  stated  in  the  contract  of  M On  the  other  hand,  when  implementors 
implement  a module  M,  they  need  only  satisfy  the  contract  of  M.(See  Figure  3)  In  the 
symbolic  evaluation  of  a program  which  uses  a module  N.  the  system  should  only  rely  on  the 
properties  of  N which  are  derived  from  the  contract  of  N. 


/ / 


II  ll 


Figure  3 

Conceptual  representations  can  be  used  to  capture  the  difference  between  the 
pureness  and  impureness  of  queue-actors.  To  do  this  the  conceptual  representation  of 
queues  must  distinguish  the  state  of  a queue-actor  in  a situation  from  its  identity  Our 
strategy  for  capturing  the  distinction  between  the  pureness  and  impureness  is  to  let  the 
conceptual  representation  describe  the  state  of  an  actor  in  a particular  situation.  For 
example,  to  state  the  fact  that  an  impure  queue-actor  has  elements  a,  b and  c in  a situation  S. 
we  use  the  following  assertion: 

(Q  it- a ( IMPURE-QUEUE  a b c))  in  S 

where  Q represents  the  identity  of  the  queue-actor  and  ( IMPURE-QUEUE  a b c)  is  the 
description  of  the  state  of  the  queue-actor.  In  order  to  differentiate  the  identity  of  an  actor, 
the  predicate  "ij-e?"  is  used.  When  there  is  a queue  Q'  such  that 

(O’  it-a  [IMPURE-QUEUE  a b c))  in  S, 
it  may  or  may  not  be  true  that 

(0  it-rq  Q'). 

A contract  for  impure  queues  includes  specifications  of  events  relevant  to  impure 
queue-actors.  (In  the  actor  model  of  computation,  a transmission  of  a message  actor  M to  a 
target  actor  T is  called  an  "event"  and  is  denoted  by  the  expression  (T  <=  M)  borrowed  from 
PLASMA  syntax.)  In  our  formalism,  a specification  of  an  event  is  expressed  in  the 
following  form. 
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[event:  (<targel-ac!or>  <=  <messaga-actor>) 

( pre-condition *:  ...<asserlion>  . ) 

(return*:  <actor» 

( post-condition* : ...Cassarlion...)  ) 

This  form  states  that  if  the  assertions  in  (pre-condition*:  ...)-dause  hold  in  the  situation 
where  the  event  takes  place,  then  the  assertions  in  (poii-rom/ii»‘on*:...)-clause  hold  in  the 
situation  where  the  actor  in  (reiurnj....)-clause  is  returned  (or  sent  to  the  continuation).  It 
should  be  noted  that  the  above  form  guarantees  the  return  of  the  actor. 

Using  this  form,  a specification  of  how  an  impure  queue-actor  is  created  is  given 
as  follows. 

(event:  (craala-impura-quaua  <=  []) 

(return*:  (neu-actor  Q)  ) 

(post-condition*:  (Q  i*-a  (IMPURE-QUEUE  ))  ) ) 

When  an  actor  croata-impura-quau*  receives  an  empty  sequence  [],  it  returns  a new  actor  Q 
where  Q is  an  empty  impure  queue.  Since  there  are  no  pre-conditions  for  this  event, 
(pre-conrfitioni:...)-ciause  is  not  used.  The  notation  (neu-actor  Q)  indicates  that  Q is  a newly 
created  actor  which  is  not  a?  (in  the  LISP  sense)  to  other  actors  ever  created  before. 
(IMPURE-QUEUE  ) is  the  conceptual  representation  of  empty  impure  queues. 

A specification  of  the  event  where  an  impure  queue  receives  a message  (nq.-...)  is  as 

follows. 


(at'anl:  (Q  <=  (nq:  A)) 

(pre-conditions:  (Q  U-a  (IMPURE-QUEUE  !*))  ) 

(return*:  Q) 

(post-condition*:  (Q  i*-a  ( IMPURE-QUEUE  !x  A))  ) ) 

Note  that  the  same  queue-actor  Q is  returned  and  the  state  of  Q has  changed  as  asserted  in 
the  (post -condition*:...).  The  specification  of  the  event  where  an  impure  queue-actor  receives 
the  message  (dq:)  is  given  in  the  complete  contract  of  impure  queues  in  Figure  4 below. 

Besides  specifications  of  events  relevant  to  the  actor  concerned,  what  has  to  be 
stated  in  contracts  is  the  conservation  of  validity  of  assertions,  from  one  situation  to  another, 
used  in  the  specifications  of  events.  For  example,  the  validity  of  the  assertion 
(0  i»-n  ( IMPURE-QUEUE  a b c))  does  not  change  after  some  other  queue-actor  QQ  receives 
(dq:)  or  (nq.  ) messages  In  other  words,  such,  an  event  does  not  cause  side-effects  which 
change  the  validity  of  the  assertion  Also  the  validity  of  this  assertion  does  not  change  even 
after  an  event  where  one  of  the  elements  of  the  queue,  say  b,  receives  some  message, 
provided  that  b is  not  the  same  actor  as  Q To  state  this  kind  of  conservation  of  validity  in 
contracts,  we  list  all  events  which  do  affect  the  validity  of  the  assertions  using  the  conceptual 
representation.  This  can  be  viewed  as  a solution  to  McCarthy’s  frame  probleml McCarthy  8c 
Hayes  1969).  In  the  case  of  assertions  of  the  form: 


• 'J4f\ 


N 


(0  «*-«  UMPURF.-QUF.UF. 


(0  <=  (n<7.-...))  and  (Q  <=  (iq:))  are  such  events.  No  other  events  affect  the  conservation  of 
the  validity  of  the  assertions  using  the  conceptual  representation  for  impure  queues  This  Is 
expressed  in  our  formalism  as  follows. 

(for-as*enion:  (Q  i*-o  {I M PURF.-QUFAIE...)) 

(only-affeeting-events-arc: 

{(0  <=  (nq:...))  (Q  <=(</,:))}  )) 

As  will  been  seen  in  Section  8,  10  and  12,  the  reasoning  in  situations  where  side-effects  are 
involved  depends  heavily  on  how  statements  are  affected  by  going  from  situation  to 
situation. 

[contracl-for  (IMPURE-QUEUF.  .)  s 

(event:  (creaU-impure-queue  <=  []) 

(return*:  (new-actor  Q)  ) 

(post-conditions:  (Q  is-a  (IMPURE-QUEUE  ))  ) ) 

(event:  (Q  <=  (nq:  A)) 

(pre-conditions:  (Q  is-a  ( IMPURE-QUEUE  !*))  ) 

(returns:  Q) 

(post-conditions:  (Q  is-a  (IMPURE-QUEUE  !x  A))  ) ) 

(event:  (Q  <=  (dq:)) 

(case- 1 : 

(pre-conditions:  (Q  is-a  ( IMPURE-QUEUE  ))  ) 

(returns:  (exhausted:)  ) 

(post-conditions:  ( Q i»-o  (IMPURE-QUEUF.  ))  ) ) 

(ease-2: 

(pre-conditions:  (Q  is-a  (IMPURE-QUEUF.  B |y))  ) 

(return*:  (next:  B (rest:  Q))  ) 

(post-conditions:  (Q  i*-a  (IMPURE-QUEUE  |y))  ) )) 

(for-assertion:  (Q  is-a  (IMPURE-QUEUF.  .)) 

(only-affecting-evenls-are: 

{(0  <=  (nq:...))  (Q  <=  (dq:)) } ))  ] 

Figure  4 

In  contrast  to  the  above  contract,  we  give  a complete  contract  for  pure  queues  in 
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Figure  5. 

[contract-for  (PURE-QUEUE.)  s 

(event:  (creale-pure-queu«  <=  []) 

(return*:  ( netn-nclor  Q)  ) 

( post-condition s:  (Q  is-a  ( PURF.-QUEUE  ))  ) ) 

(event:  (Q  <=  ( nq : A)) 

(pre-condition*:  (Q  i*-o  (PURF.-QUEUE  |x))  ) 

(return*:  ( nru-actor  Q')  ) 

(port-condition*: 

(Q*  i*-a  (PURF.-QUEUE  !x  A)) 

(Q  «*-«  (PURE-QUEUE  !x))  ) ) 

(event:  (Q  <=  (dq:)) 

(ea.tr- 1: 

(pre-condition*:  (Q  i*-a  (PURE-QUEUE  ))  ) 

(returns:  ( exhausted :)  ) 

(port-conditions:  (Q  i*-a  (PURE-QUEUE  ))  ) 

(e.a*e-2: 

(pre-conditions:  (Q  it-a  (PURE-QUEUE  B !y))  ) 

(returns:  (next:  B (reul:  ( newactor  Q')  )) 

(post-conditions: 

(O’  is-o  (PURE-QUEUE  !y)) 

(0  i*-o  (PURE-QUEUE  B !y»  ) ))  ] 

Figure  5 

The  important  fact  stated  in  the  above  contract  is  that  every  time  a pure  queue-actor 
receives  (dq:)  or  (nq:...)  messages,  a new  pure  queue-actor  is  created  and  that  the  state  of  the 
original  queue-actor  does  not  change.  In  fact  the  state  of  each  pure  queue-actor  never 
changes  after  it  is  created,  which  implies  that  assertions  about  the  state  of  pure  queue-actors 
are  always  valid.  Therefore  the  (for-ass^rtions: ...)-dause  is  not  necessary  in  the  contract  for 
pure  queues.  In  Appendix  II  a contract  for  cell-actors  is  given  in  the  same  formalism. 

It  should  be  remarked  that  since  the  actor  model  of  computation  serves  as  the 
underlying  semantics  of  various  programming  languages  such  as  SIMULA-67[Dahl  et  al 
1968],  CLUlLiskov  1974,  Schaffert,  Snyder  Sc  Atkinson  1975],  ALPHARDlWulf  1974]  and 
SMALL  TALKtLearning  Research  Croup  1976],  these  contracts  are  not  biased  by  the 
language  in  which  implementations  are  written,  because  the  contracts  can  be  precisely 
interpreted  in  terms  of  the  actor  model  of  computation. 


7.  A CONTRACT  FOR  EMPTY-ONE-QUEUE-INTO-ANOTHER 


In  this  section  we  will  give  the  code  and  contract  for  an  actor  which  is  supposed  to 
transfer  elements  (i.e.  queuees)  of  one  impure  queue  to  another  impure  queue.  This  code 
and  contract  will  be  used  to  illustrate  the  symbolic  evaluation  in  Section  10.  We  present  the 
contract  for  this  actor  (Figure  6)  before  presenting  its  concrete  implementation.  Other 
modules  which  use  empty-one*queue-into>another  below  should  rely  only  on  properties  that 
can  be  derived  from  the  contract  given  hellow. 

[contract-for  ampty-one-queue-into-another  s 

(event:  (ampty-one-quaua-inlo-anothar  <=  [Q1  Q2]) 

( pre-conditions : 

(Q 1 •*-«  UMPURF.-QUF.UK  !xl)) 

(Q2  is-o  UMPURF.-QUF.UF.  !x2)) 

(Ql  not-cq  Q2)  ) 

{returns:  {done:  {emptied:  Ql)  {extended:  Q2))  ) 

{post-conditions: 

(Ql  is-o  U M PURR-QUF.UF.  )) 

(Q2  is-o  UMPURK.-QUK.UK.  !x2  Jxl))  ) ) ] 

Figure  6 

Figure  7 below  shows  an  implementation  of  this  actor  in  PLASMA. 

(<nama>:  <alamants>)  is  an  expression  which  stands  for  an  actor  called  a "package". 
Packages  are  analogous  to  records  in  some  languages.  Examples  of  packages  in  Figure  7 are 
{dq:)t  { ncxt:...(rr.u ;...)),  {nq:...)  and  {done:  {emptied:...)  {extended:...)).  A similar  implementation 
in  CLU[Schaffert,  Snyder  & Atkinson  1975]  is  found  in  Appendix  III. 


{ 
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(•mpty-ona-quaiM-into-anothvr  s 

(=>  [=ql  =q2]  ;lioo  impure  queue*  are  rereived  hy  •mpty-on»-qu#'j**-into-artoth«r 

;and  hound  to  ql  and  q2. 

(rules  (ql  <=  ( dq :))  ;l he  dequeuing  menage  it  tent  to  ql. 

(=>  (exhausted:)  ;!/  ql  ii  empty,  the  complaint  menage  it  received 

(done:  ( emptied : ql)  ( extended : q2))  ) \then  emptied  ql  and 

; extended  q2  are  returned. 

{»/  ql  it  not  empty,  the  front  clement  of  ql  and 
; the  remaining  queue  are  received 
;and  hound  to  front-of-ql  and  daqueued-ql. 
;fronl-of-ql  it  enqueued  at  rear  of  q2. 
i [dequ«uod-ql  q2]))  ) )) 

ql  and  q2  are  tent  to  amply-ona-queua'into-another. 

Figure  7 

One  should  note  that  the  implementation  in  Figure  7 crucially  depends  on  the  fact 
that  queue-actors  referred  to  by  ql  and  q2  are  impure  actors.  If  ql  and  q2  are  pure  actors, 
then  every  time  (dq:)  or  (nq:...)  messages  are  sent,  a new  queue-actor  would  be  created,  but  ql 
and  q2  would  still  refer  to  the  same  queue-actors  to  which  they  originally  referred. 
Therefore  after  completing  of  the  evaluation  of  empty-one-queue-into-another,  the  original 
queue-actors  referred  to  by  ql  and  q2  would  remain  intact,  which  would  violate  the  contract 
in  Figure  6.  Also  note  that  if  the  original  queue-actor  refered  to  by  ql  is  a pure  queue-actor, 
then  ql  and  d*queu«d-ql  would  always  denote  different  queue-actors. 


(s>  (next:  =fronl-of-ql 

(real:  =daquaued-ql)) 

(q2  <=  (nq:  fronl-ot-ql)) 
(•mpty-ona-quaua-into-anolher  <= 
{dequeued- 


8 SYMBOLIC  EVALUATION  AND  SITUATIONS 


In  this  section  we  give  an  overview  of  symbolic  evaluation  Also  important  rules 
in  our  reasoning  system,  called  trans-si  tuational  rules,  are  explained.  As  briefly 
mentioned  before,  symbolic  evaluation  is  a process  which  abstractly  evaluates  a module  on 
abstract  data  in  the  context  of  its  contract  If  the  symbolic  evaluation  of  a module  M 
encounters  an  invocation  of  some  module  N.  then  the  contract  of  N is  used  to  continue  the 
symbolic  evaluation.  The  implementation  of  N is  not  used!  The  purpose  of  symbolic 
evaluation  is  to  gather  information  for  various  purposes  such  as  verification  that  the 
implementation  satisfies  its  specification,  question  answering  for  debugging,  perturbation 
analysis[Hewitt  Sc  Smith  1975],  and  refinement  of  the  implementation. 

In  symbolic  evaluation,  the  code  of  a program  is  interpreted  step  by  step  according 
to  either  pre-defined  semantics  of  language  primitives  or  contracts  of  modules  invoiced  in 
the  program.  Each  such  step  is  triggered  by  the  symbolic  evaluation  of  an  expression  in  the 


code.  The  state  of  the  program  at  each  moment  before  or  after  such  interpretation  steps  is 
refered  as  a situation.  The  symbolic  evaluator  has  a data  base  to  record  what  events 
happen,  what  facts  hold  and  what  is  assumed  in  each  situation.  Facts  that  hold  in  a 
situation  S are  recorded  as  assertions  associated  with  the  situation  S Since  the  interpretation 
of  each  expression  is  performed  on  abstract  data,  when  a conditional  expression  is 
interpreted,  the  subsequent  symbolic  execution  path  must  split  in  the  usual  fashion  For 
example,  consider  the  symbolic  evaluation  of 

if  (P  x)  then  ...  elite  .... 

After  the  symbolic  evaluation  of  the  expression  (P  x),  the  symbolic  execution  path  splits  into 
two  branches:  one  for  then-clause  and  the  other  for  else-dause.  To  start  the  subsequent 
symbolic  evaluation,  (P  x)  must  be  assumed  for  then-clause  and  -t(P  x)  for  else-dause.  If  the 
evaluation  of  (P  x)  has  no  side-effects,  the  assertions  holding  in  the  situation  where  IP  x)  is 
evaluated  are  inherited  for  both  clauses. 

Symbolic  evaluation  can  be  viewed  as  a process  which  evaluates  the  code  forward 
along  the  execution  path  and  produces  a tree  structure  whose  nodes  correspond  to  situations. 
At  each  node  of  such  a tree  structure,  assertions  which  hold  in  the  corresponding  situations 
can  be  entered.  We  call  this  tree  structure  a situational  tree.  (See  Figure  8.)  The 
assertions  in  the  situational  tree  are  used  as  the  primary  source  of  information  for 
answering  questions  about  the  implementation. 

In  what  follows,  we  illustrate  how  a situational  tree  is  used.  In  general  questions 
about  a given  situation  are  answered  by  reasoning  backward  to  previous  situations. 
Suppose  that  the  system  is  asked  whether  or  not  a certain  impure  queue,  say  Q,  has  elements 
a b and  c in  a situation  S8.  First,  the  system  tries  to  find  an  assertion 

(Q  i»-a  (I If  PURF.-QUKUK  a b cl)  at  the  node  of  the  situational  tree  which  corresponds  to  S#. 
If  it  is  found  there,  the  answer  is  "yej"-  but  it  <s  not  found  there,  the  system  looks  for  the 
assertion  (Q  #*-«  ( IMPUKK-QUF.UE  a b c))  backward  along  the  branch  of  the  situational  tree 
from  the  node  of  S#.  Suppose  that  the  assertion  is  found  at  the  node  of  a situation  S3.  (See 

a dotted  line  in  Figure  8)  All  we  know,  at  this  point,  is  that  the  assertion  holds  in  Sy  but  it 
is  not  sure  that  the  assertion  holds  in  S#.  because  some  events  which  destroy  the  validity  of 
this  assertion  in  S8  might  have  happended  between  S}  and  S#. 


S3:  (0  i.-a  UMPURK-QUF.UF.  a b e)) 

I * 


Figure  8. 

So  the  system  has  to  check  whether  or  not  such  events  have  happened.  In  this  case,  in  order 
to  know  what  events  destroy  the  validity  of  the  assertion,  the  system  consults  the  contract  of 
(/ M PURK-QUKUK...)  given  in  Figure  4 and  finds  out  the  events  (0  <»  (</*.•))  and  (0  <»  (n«j:...)) 
In  the  (/br-<merii0n«:...)-clause.  Thus  the  answer  to  the  original  question  whether  or  not  (0 
i*-o  UM PURK-QUKUK  a b c))  holds  in  Sg  is  "ye*"  if  neither  (Q  <»  (d7.))  nor  (Q  <»  («7-...)) 
have  happened  between  S}  and  Sg. 

The  process  working  forward  in  interpreting  each  expression  also  relies  on  the 
process  retrieving  the  situational  tree  backward.  Suppose  that  an  event  (Q  <=  (n7:  d»  takes 
place  in  Sg  in  the  above  example.  To  get  the  state  of  the  actor  Q in  the  next  situation  S9, 

the  system  wants  to  know  the  state  of  Q in  Sg.  which  is  not  found  the  at  the  node  of  Sg.  So 

the  system  tries  to  retrieve  the  information  using  the  situational  tree  backward  in  the  same 
manner  as  above. 

In  general  the  information  which  indicates  what  conditions  assure  the  conservation 
of  validity  of  assertions  from  one  situation  to  another  is  called  a trans-situational  rule. 
For  particular  assertions  or  particular  types  of  assertions,  appropriate  trans-situational  rules 
are  necessary  for  correct  reasoning.  In  what  follows,  we  will  give  trans-situational  rules 
which  will  be  used  in  the  examples  of  symbolic  evaluation  in  this  paper. 

Assertions  of  the  form:  (<idantifiar>  s < actor)) 

which  states  that  <aclor>  is  bound  to  <idantifier>,  can  be  passed  unchanged  between  any  two 
situations  within  the  scope  of  <identifi#r>. 

Assertions  of  the  forms:  «actorl>  r<j  <actor2»  and  «actorl>  not-eq  < actor  2>), 
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which  state  the  identity  of  actors  can  be  always  inherited  from  one  situation  to  another 
without  any  conditions. 

Assertions  of  the  forms:  (<t«quanc«l>  = <*tqu«nc«2>)  and  (<saqu«nc«l>  * <saqu«nc«2>), 

which  state  the  equality  sequences  which  appear  in  conceptual  representations  can  be  also 
inherited  without  any  conditions.  (Note  that  <s«quanc«l>  and  <caquanc»2>  are  not 
sequence-actors  but  mathematical  sequences.  All  mathematical  facts  can  be  inherited  without 
any  conditions.  This  is  a special  case.) 

Assertions  of  the  form:  (<actor>  ii-«  {SEQUENCE  !x)) 

which  states  that  <actor>  is  a sequence-actor  whose  elements  are  |x  can  be  inherited  without 
any  conditions  because  a sequence-actor  is  a pure  actor  which  never  changes  its  state. 

Assertions  of  the  form:  (<»elorl>  knouit-about  <actor2» 

which  state  the  knows-about  relation  between  actors  can  be  inherited  without  any  conditions. 

Assertions  of  the  form:  (CvariabW)  ha«-ronieiti«  <actor>) 

which  state  that  <variabla>  has  <actor>  as  its  contents  in  some  situation  S can  be  inherited  to  a 
situation  T if  no  assignments  to  this  <variabl«>  take  place  between  S and  T. 


9.  SYMBOLIC  EVALUATION  AND  NAMES 


Before  we  give  a concrete  example  of  symbolic  evaluation,  we  wilt  explain  the  use 
of  names  in  symbolic  evaluation.  Names  in  PLASMA  fall  into  two  classes:  identifiers 
and  variables.  An  identifier  x can  be  declared  and  bound  to  the  value  of  an  expression  E 
by 

(/e«(x-E)...  ). 

I 

A variable  x can  be  declared  and  initialized  with  the  value  of  an  expression  E by 
(/el  (x  initially  E)...  ). 

The  above  statement  is  Implemented  by  creating  a new  cell-actor  C whose  initial 
contents  are  the  value  of  E and  binding  x to  C.  Evaluation  of  x is  implemented  by  retrieving 
the  contents  of  C.  The  value  of  x can  be  changed  only  by  an  expression  of  the  form: 


and  this  is  implemented  by  updating  the  contents  of  C with  the  value  of  E.  PLASMA  has 
been  carefully  designed  so  that  there  is  no  way  to  release  the  cell-actor  C to  other  actors.  In 
order  to  state  that  a variable  x has  an  actor  A as  its  value  in  a certain  situation,  the 
following  assertion 

(x  hat-eonlenlt  A) 

is  used  in  symbolic  evaluation.  When  an  expression 
(x  *•  E) 

is  interpreted  in  a situation  S,  the  following  assertion 
(x  hat-eonlent*  B) 

is  entered  in  the  situation  following  S where  B is  the  value  of  E in  S. 

In  the  symbolic  evaluation  of  a module  , an  identifier  x in  the  code  of  module  can 
be  always  regarded  as  the  actor  which  is  bound  to  x.  because  one  identifier  does  not  bind 
more  than  one  different  actor  throughout  the  symbolic  evaluation  of  M.  This  is  guaranteed 
by: 

1)  the  restriction  on  the  syntax  of  PLASMA  that  no  names  are  allowed  to  be  rebound 
inside  a module  (referential  transparency)  and 

2)  the  fact  that  symbolic  evaluation  passes  over  each  expression  in  a module  exactly  once. 
For  example,  let  us  consider  the  following  piece  of  code. 

Uel  (queue-1  8 (creale-impure-queue)) 
then 

(/el  (queue-2  = queue- 1) 

In  the  first  statement  an  empty  impure  queue-actor  Q is  created  and  bound  to  an  identifier 
queue-1.  To  record  this  event,  instead  of  using  two  assertions: 

(Q  U-n  {I M PURR-QUEUE  )) 

(queue- 1 « Q). 

one  assertion: 

(queue-1  i»-n  ( IMPURE-QUEUE  )) 

suffices  our  purposes  This  type  of  assertions  will  be  frequently  used  in  Section  12.  By  the 
second  statement  in  the  above  code,  the  assertion: 
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(qu«u«-2  rq  queue- 1) 

will  be  entered  in  the  data  base  and  it  tells  the  actor  bound  to  queue-2  is  the  same  actor 
denoted  by  queue-1.  The  question  about  the  identity  of  queue-2  and  queue-1  is  answered  by 
this  assertion,  (cf.  Section  5) 


10.  AN  EXAMPLE  OF  SYMBOLIC  EVALUATION 


As  an  example  of  symbolic  evaluation,  let  us  consider  the  symbolic  evaluation  of 
the  code  of  empty-one-queue-into-another  in  Figure  7 in  Section  7 In  this  example,  we 
assume  that  the  system  tries  to  verify  the  implementation  of  empty-one-queue-inlo-another 
against  its  contract  given  in  Figure  6 in  Section  7.  In  order  to  ease  the  interaction  between 
the  system  and  users  and  also  to  aid  the  symbolic  evaluation,  programs  should  be 
augumented  with  commentary  which  denotes  situations  or  identify  important  parts  of  code. 

• In  Figure  9 the  augumented  code  of  •mpty-onw-queuc-into-anothar  is  given.  (This 

augumentation  in  Figure  9 is  solely  for  the  purpose  of  the  presentation  of  this  paper.  For 

our  existing  system,  somewhat  different  augumentations  are  used ) The  large  capital  letters 

S between  the  lines  denotes  situations. 

... 
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(empty-one-qu0ue-into~anothar  = 

(=>  l=ql  =q2]  ;luo  impure  queue % are  received  by  0mpty*on»-'queu«*'mto-anoth«r 

{and  bound  to  ql  and  q2. 

- s 

r • c«  i ved-queu«s 

(rules  (ql  <=  (dq:))  ; the  dequeuing  mettage  it  tent  to  ql. 


(=>  [exhausted:)  ;if  ql  is  empty,  the  complaint  mettage  it  received 

- s 

exhausted -ql 

(done:  ( emptied : ql)  (extended:  q2))  ) ;tben  emptied  ql  and 

{extended  q2  are  returned. 


(=>  (next:  =front-of-ql 

(rest:  =dequauad-ql)) 


-S 


dsqusuad-ql 


;if  ql  is  not  empty,  the  front  element  of  ql  and 
;lhe  remaining  queue  are  received 
{and  bound  to  front*ol~ql  and  daquauad-ql. 


W (n9:  (ronl-ol-ql))  ;front"Ol*ql  it  enqueued  at  rear  of  q2. 

-s 

•nqu*u*d-q2 

(ampty-one-queua-into-another  <=  [dequaued-ql  q2]))  ) )) 

;daquauad-ql  and  q2  are  tent  to  ampty-ona-quaua-into-anothar. 


Figure  9 

Symbolic  evaluation  of  a module  takes  place  in  the  context  of  the  specifications  of 
the  module.  Thus  in  the  case  of  this  example,  the  symbolic  evaluator  reads  the  contract  of 
ampty-ona-quaua-inlo-anolhar  in  Figure  6 and  enters  the  following  assertions  which  are  the 
pre-requisites  of  empty-ona-queua-into-another  in  the  data  base. 

faSlall.a.  ! 

(Ql  it-a  ( IMPURK-QUF.UF.  |xl)) 

(Q2  it-a  (IMPURE-QUEUE  »x2)) 

(Ql  not-eq  Q2) 


After  the  symbolic  pattern  matching  is  performed,  Ql  and  Q2  are  bound  to  identifiers  ql 
and  q2,  respectively  So  the  following  assertions  are  entered  in  the  data  base. 

in  S : 

r«c«t v«d-qu4u»s 

(ql  s Ql) 

(q2  = Q2) 


Then  the  expression  (ql  <=  (dq-.))  in  the  rulas-statement  is  interpreted.  Namely,  the 
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dequeuing  message  (dq.)  is  sent  to  Q1  which  is  bound  to  ql.  To  know  the  result  of  this 
event,  the  symbolic  evaluator  must  consult  the  (e»rm...)  clause  for  dequeuing  in  the  contract: 

( event : (Ql  <=  (dq:)) 

(case-1: 

( pre-condition (Ql  i*-o  (IMPURE-QUEUE  ))  ) 

( return s:  [exhausted:)  ) 

[post-conditions:  (Ql  is-o  [IMPURE-QUEUE  ))  ) ) 

[cate-2: 

(pre-conditions:  (Ql  is-a  ( IMPURE-QUEUE  B !y))  ) 

[returns:  (next:  B (rest:  Ql))  ) 

(post-conditions:  (Ql  is-a  (IMPURE-QUEUE  !y))  ) )) 


Note  that  the  above  clause  is  an  instantiation  of  the  (et>em...)-clause  for  the  dequeuing  in  the 
contract  for  impure  queues  in  Figure  4,  which  is  obtained  by  substituting  Ql  for  Q.  Now  the 
symbolic  evaluator  has  to  consider  two  case:  one  case  where  Ql  is  empty  and  the  other  case 
where  Ql  is  not  empty.  (See  the  situational  tree  for  this  example  in  Figure  10.) 


S 


Initial 


Figure  10 


•nquaua4-q2 

\ 


Case  I:  (Ql  is-a  (IMPURE-QUEUE  )) 

In  this  case,  the  contract  specifies  that  the  (exhausted:)  message  is  returned.  This  message 
matches  against  the  first  (s>...)-statement  inside  the  (rules...)  statement.  To  follow  this  path, 
the  symbolic  evaluator  needs  to  assume  that  xl  = [)■  So  in  S#Bhaut ud  r the  following 
assertions  are  entered  in  the  data  base. 


7* 
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in  o u A . , : 

mhauited-ql 

<*i  = []) 

(Q 1 it-a  U MPURE-QUF.UF.  )) 

Then  in  ^t)(haull,d.ql  tbe  message  (done:  ( emptied : ql)  ( extended q2))  is  returned.  At  this 
point  the  contract  of  emply-one-queue-into-anolher  in  Figure  S requires  three  things: 

rl:  {done:  (emptied:  Ql)  ( rxirndrd : Q2 ))  must  be  returned 
r2:  (Ql  it-a  (IMPURE-QUEUE  ))  must  hold  and 
r3:  (Q2  it-a  ( IMPURE-QUEUE  Jx2  Jxl))  must  hold 


It  is  easy  to  show  that  each  requirement  is  satisfied  in  S 


•xhaus t«d-qi' 


for  rl,  since  the  trans-situational  rules  for  binding  allow  the  inheritance  of  the 


to  S.»h.u.i.d-qr  ,he  squired 


•xhaus  t®d-ql* 


assertions  (ql  h Ql)  and  (q2  a Q2)  from  Srtctivt(J_qu#uti  to  S#llMgt|.d_ql.  the  required 
message  is  returned  in 

for  r2,  since  the  assertion  (Ql  it-a  (IMPURE-QUEUE.  ))  is  entered  in  S . . ,,  it 

•xhaus tsd-ql* 

holds  in  S . . . , and 

•xhaust«d-ql 

for  r3,  (Q2  it-a  (I M PURE-QUEUE  Jx2))  hold  in  ^,>haustt(J.qi  because  it  can  be 
inherited  from  S(nitu)  by  the  trans-situational  rule  for  (<actor>  it-a  (IMPURE-QUEUE  ...)) 
and  the  following  fact  about  sequences  can  be  used  because  xl  = []  holds  in  S 


• «h*us  lad-ql' 


[Jx2  !xl]  is  equivalent  to  [Jx2]  if  xl  is  equal  to  []. 


So  (Q2  it-a  (IMPURE-QUEUE  Jx2  Jxl))  holds  in  S,xhaut„d  v Thus  Case-1  is  done. 


Case-2:  (Ql  i*-n  (IMPURE-QUEUE  B Jy)) 

In  this  case,  the  contract  specifies  that  (n<*ri:  B (reti:  Ql))  is  the  result  of  (ql  <=  (dq:))  where 
the  following  assertions  are  assumed. 

(xl  = [B  Jy)) 

(Ql  it-a  (IMPURE-QUEUE  Jy)) 

§o  inert:  B (mi:  Ql))  is  matched  against  the  pattern  in  the  first  (=>...)  statement  inside  of 
the  (rules  ) statement  The  symbolic  evaluator  also  asserts  the  binding  information  in 
S 

dtqueued-ql 

in  S.  s 

d*qu«utd-ql 

(fronl-of-ql  s B) 

(dequeued-ql  = Ql) 

(xl  = (B  Jy)) 

(Ql  it-a  (IMPURE-QUEUE  Jy)) 


• : 


Then  in  this  situation  (nq:  B)  message  is  sent  to  Q2  which  is  bound  to  q2  and  the  assertion 
(Q2  i.«-c  ( IMPURE-QUEUE  *x2))  holds  because  it  can  be  inherited  from  S ..  . by  the 
trans-situational  rule  for  «actor>  it-a  (/ M PL  RE-QUEUE...)).  From  the  instantiated  clause  for 
the  event  (Q2  <=  (117:  B)). .)  of  the  contract  in  Figure  4 (note  the  substitutions  of  Q2  for  Q.  m2 
for  x,  and  B for  A.) : 

(event:  (Q2  <=  (*17:  B)) 

( pre-conditions : (Q2  i*-n  (IMPURE-QUEUE  *x2))  ) 

(return*.-  Q2) 

{post-conditions:  (Q2  is-o  (IMPURE-QUEUE  !x2  B))  ) ) 
the  symbolic  evaluator  enters  the  following  assertion  in  S . 

' o qnqu«u*d-qZ 


in  o ^ ,j 

•nqu«utd-qZ 

(Q2  is-a  ( IMPURE-QUEUE  Jx2  B)) 

Now  the  symbolic  evaluator  encounters  the  transmission  of  Q1  and  Q2  to 
amply -ona-quaua-inlo-anolher  in  S>n()ufu#d  q,.  Then  in  order  to  know  the  behavior  of  the 
•mpty-one-quaua-into-anothvr,  the  symbolic  evaluator  refers  to  the  contract  f or 
•mply-one-quaua-into-anothar  in  Figure  6.  (Note  that  this  is  a "recursive"  use  of  the  contract.) 
Since  the  assertions 

(Q 1 it-a  ( IMPURE-QUEUE  !y))  and  (Q1  not-cq  Q2) 
can  be  inherited  from  S_  . . by  the  trans-situational  rules  for 

d«qu«ucd-ql  • 

«aclo r>  is-a  (IMPURE-QUEUE...))  and  «aelorl>  not-eq  <aclor2». 

respectively,  the  following  pre-conditions  of  amply -on*-quau*-inlo-anolhar  are  satisfied. 

(Q 1 it-a  ( IMPURE-QUEUE  !y)) 

(Q2  it-a  ( IMPURE-QUEUE  fx2  B))  and 
(Q1  not-rq  Q2) 

Therefore  the  post-conditions  of  the  contract  for  amply-one-queua-inlo-anolher  guarantees 
that  (done:  (emptied:  Ql)  ( extended : Q2))  is  returned  and  that  the  following  assertions: 

(Q 1 it-a  (IMPURE-QUEUE  ))  and 
(Q2  it-a  (IMPURE-QUEUE  ![Jx2  B]  Jy)) 

hold  in  the  situation  following  Then  the  following  knowledge  about  sequences 

is  used  to  simplify  the  above  assertions: 
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[![!*2  B]  Jy]  is  equivalent  to  [!x2  B !y], 

[!*2  B !y]  is  equivalent  to  [Jx2  Jxl]  if  xl  = [B  »y] 

Since  xl  = (B  !y]  can  be  inherited  from  S-tququqd_ql  by  the  trans-situational  rule  for 
(<soqu«nc«l>  = <s«qu«nc*2>),  the  symbolic  evaluator  can  claim  that 

(Q1  ix-a  (/ M PURF.-QUEUE  ))  and 
(02  it-a  UMPVKE-QUF.uk  !x2  Jxl)) 

Thus  the  post-conditions  for  empty*on»-qu*u*-into-anolher  are  also  satisfied  in  Case-2. 

Since  the  requirements  stated  in  the  contact  for  emp(y-on*-queu«-inlo-anoth»r  are 
satisfied,  we  conclude  that  the  implementation  of  empty-one-queue-into-anothar  in  Figure  7 is 
guaranteed  to  meet  its  contract  in  Figure  6.  It  should  be  noted  that  the  above  assertions  are 
guaranteed  to  hold  in  a given  situation  only  if  control  passes  through  that  situation.  There 
is  no  guarantee  that  any  of  situations  after  sr,c,(vtd.qu,u„  above  will  ever  be  reached. 
Therefore  the  demonstration  of  convergence  is  another  part  of  the  symbolic  evaluation  that 
can  be  incorporated  into  the  above  symbolic  evaluation.  As  we  mentioned  in  Section  5. 
explicit  use  of  situational  tags  is  powerful  to  the  formal  demonstration  of  the  convergence. 
For  a detailed  demonstration  of  the  convergence,  see  [Yonezawa  1975] 

II.  AN  IMPLEMENTATION  FOR  IMPURE-QUEUE 


In  the  symbolic  evaluation  of  •mpty-one-qu#u«-into-*noth«r.  the  only  properties  of 
impure  queues  used  were  only  the  ones  given  in  the  contract  for  impure  queues  in  Figure  4. 
This  fact  guarantees  that  •mply-one-qu«u*-into-»nother  satisfies  its  specification  on  all 
implementations  of  impure  queues  that  satisfy  the  contract  in  Figure  4.  Now  we  give  an 
example  of  an  implementation  of  an  impure  queue  which  is  supposed  to  satisfy  the  contract 
in  Figure  4.  The  PLASMA  code  depicted  in  Figure  II  is  such  an  implementation.  Note  that 
queuees  is  an  example  of  a PLASMA  variable  explained  in  Section  9.  So  the  value  of 
quouees  changes,  but  other  names  such  as  n*w«Um»nt,  th«-queue-its»lf,  front  etc.  are 
identifiers  and  thus  are  bound  to  the  same  actor  throughout  their  scope 


*•  •K' 
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(creit«*impur*-qu«ua  = 

I=>  II  .*r«sta*impura-quaoa  rrerivri  an  empty  tequenee. 

(let  (qutUHl  initially  [])  ;a  variahle  qu*u«*s  it  declared 

then  ;and  initialized  i eith  an  empty  tequenee. 

(tha-quaua-itsalf  = ya  queue-artor  it  defined  hy  the  ratet-ttaiemenl  given  helow 

;and  denoted  hy  tha-quaua-itsalf. 

(cases 

(=>  (nq:  snaw-alamant)  ‘.when  an  enqueue  menage  with  an  element  it  received. 

;lhe  element  it  hound  to  naw-alamant. 
(quauaas  •*  [jqutUMS  naw-alamant])  ;«  new  tequenee-aetor  who  to  element*  are 

;the  unpack  of  the  value  of  quauaas  and  naw-alamant 
;i*  created  and  ttored  in  quauaas. 
tha-quaua-itsalf)  ;«n<f  then  tha-quaua-itsalf  is  returned. 


(=>  (dq:) 

(rules  quauaas 

(=>  []  (exhautted:)  ) 

(=>  [=front  !=rast] 

(quauaas  *-  rasl) 

(nrjri:  front  (reti:  tha-quaua*itsalf)) 


{when  a dequeue  menage  it  received, 
\if  the  content * of  quauaas 
tit  empty,  then  the  menage  it  returned. 
;olherwi*e  the  firtl  element  is  hound  to  front 
;and  the  rett  of  the  element * it  hound  to  rest. 

Jit  he  value  of  quauaas  is  updated. 
) ))  ))))  ilneti:...)  it  returned. 


Figure  11 


The  basic  idea  of  this  implementation  is  presented  as  a diagram  in  Figure  12.  An  impure 
queue-actor  tha-quaua-itsalf  consists  of  a variable  quauaas  which  has  a scquence-actor  S as  its 
value.  The  elements  of  this  sequence-actor  S are  the  members  of  the  queue.  In  the  diagram 
arrows  indicate  which  actors  directly  reference  others  (i.e.  the  knows-about  relation),  (cf. 
Section  3)  Since  tha-quaua-itsalf  returns  itself,  tha-quaua-itsalf  must  know-about 
tha-quaua-itsalf. 


the-queue-i tsel f 


Figure  12 

The  diagram  in  Figure  12  is  not  only  a partial  and  static  description  of  the  above 
implementation,  but  it  also  expresses  invariant  or  integrity  conditions  which  must  be 
satisfied  among  the  constituents  of  the  implementation  before  and  after  each  invocation. 
Thus  an  important  property  of  the  implementation  can  be  expressed  formally  as  the 
following  invariant  statement. 

(Invariant:  (fhe-queue-ifsalf  b-a  (IMPURE-QUEUE  fa)) 
where  (tha-quaua-itsalf  knowt-nhoui  quauaas) 

(tha-quaua-itsalf  knotrt-nbout  tha-quaua-itsalf) 

(quauaas  hat-contents  $) 

(S  ii-a  (SEQUENCE  fa))  ) 

This  states  that  the  assertion  (iha-quaua-ilsall  it-a  (IMPURE-QUEUE  fa))  is  an  invariant. 
When  this  assertion  holds,  tha-quaua-itsalf  has  acquaintances  quauaas  and  tha-quaua-itsalf 
(namely,  (tha-quaua-itsall  knowt-abont  quauaas)  and  (tha-quaua-itsalf  knewt-ahout 
tha-quaua-itsalf)  hold},  the  variable  quauaas  has  a sequence-actor  S as  its  value  (namely, 
(quauaas  ha»-ronicnit  S)  j and  S has  fa  as  its  elements.  A notation  (SEQUENCE...)  is  the 
conceptual  representation  of  a sequence-actor. 


A similar  implementation  written  in  CLU  is  found  in  Appendix  IV.  These  two 
implementations  exhibit  the  same  computation  sequence  in  terms  of  the  actor  model  of 
computation. 


12.  SYMBOLIC  EVALUATION  OF  IMPURE-QUEUE 


Now  we  proceed  to  the  symbolic  evaluation  of  cr#«U-impur»-qu*u*  in  Figure  11 
against  its  contract  in  Figure  4.  This  time  our  interest  is  not  only  in  the  demonstration  that 
the  implementation  satisfies  its  specification,  but  also  in  the  internal  structure  of  the  code 
which  will  be  exposed  during  the  process  of  symbolic  evaluation.  The  code  of 
craaU-impure-queu*  in  Figure  13  is  augumented  with  situational  tags  and  the  (Invariant:) 
statement  which  was  introduced  in  Section  II.  In  general  (Invariant:...)  statements  not  only 
express  the  invariant  or  integrity  conditions  of  actors  which  behave  like  data  structures,  but 
also  they  express  inductive  assertions  when  they  are  used  inside  iterative  programs. 
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(craale-impure-quaue  = 

(=>  [J 

Vet  (quauaas  initially  [)) 
then 

- s 

ini  t la  I izid-quiutu 


;craata-impura-qu«ua  rrceiret  an  empty  tequence. 

f°  variable  queues*  it  declared 
;and  initialized  with  an  empty  tequenre. 


(tha-queua-itsaH  = 

- s 

nq-or-dq-ini t i* I 

( Invariant : (the-queue-itsell  it-a  ( IMPURE-QUEUE  ••)) 
inhere  (the-queue-itsell  knout- about  queues*) 

(the-queue-itself  knouit-abou t the-queue-itself) 
(quauaas  hat-content  t $) 

(S  it-a  [SEQUENCE  !•))  ) 


;a  queue-actor  it  defined  by  the  catet-ttalemenl  given  belout  and  denoted  by  the-queue-itself 
(cases 

(=>  [nqi  =naw-a)amant)  ;uhen  an  enqueue  menage  with  an  element  it  received. 

element  it  bound  to  new-element. 

r«c«  i vtd-nq 

(quauaas  - [.'quauaas  new-element])  ;«  „ru)  nquenre-aetor  uhnte  elementt 

;are  tbe  unpack  of  tbe  value  of  quauaas  and  new-element 
it  created  and  it  ttored  in  quauaas. 


- s 

the-queue-itself) 
(=>  (dq:) 


updi I «d-qutu»*j -nq 


- s 


(rulas  quauaas 

<s>n 


raea ivtd-dq 


- s 


( exhausted :)  ) 
(=>  [sfront  !=rasl] 


•*ply-q 


- s 

non-aap ly-quauaai 
(quauaas  *-  rast) 

- S 

upda lad-quauaas -dq 

[next:  front  (rr.«i:  the-queue-itself))  ) ))  ))  )) 

Figure  13 


;onrf  then  tha-quaua-itsalf  it  returned, 
iwhen  an  dequeue  met.-age  is  received, 

iif  the  value  of  quauaas 
;is  empty 

‘.then  the  complaint  mettnge  it  returned. 

;otheruite  tbe  firtl  element  it  bound  to  front 
;and  tbe  ret  I of  tbe  elementt  it  bound  to  rast. 


itbe  commit  of  quauaas  it  updated. 

;(nr*»:.„)  is  returned. 


The  symbolic  evaluation  of  the  code  in  Figure  13  is  carried  out  in  the  context  of 
the  contract  of  impure  queues  in  Figure  4 There  are  four  clauses  in  the  contract:  one  clause 
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each  for  the  creation,  enqueuing  and  dequeuing,  and  one  clause  for  the  trans-situational  rule 
for  assertions  of  the  form  (0  i*-a  UMPIRE-QUEUE...))  As  seen  in  the  symbolic  evaluation 
of  •mpty-on«-qu»ue-into-*noth«r  in  Section  10.  trans-situational  rules  are  vital  for  reasoning 
in  situations  where  side-effects  are  involved.  Therefore  it  is  necessary  to  establish  the 
trans-situational  rule  in  the  contract  for  impure  queues  as  well  as  the  specifications  of  the 
creation,  enqueuing,  and  dequeuing.  In  what  follows,  the  four  clauses  in  the  contract  are 
established  separately. 

I.  Establishing  the  CREATION  specification 

The  symbolic  evaluator  reads  the  first  (*««ni:...)  clause  in  the  contract  for 
UUPURF.-QUKUF.  .)  in  Figure  4: 

(event:  (cr*»t#-impur#-qu*u*  <s  []) 

(returns:  (nrtc-actor  Q)  ) 

(pott-conditiont:  (Q  ii-a  ( IMPURE-QUEUE  ))  ) ). 

Since  there  are  no  pre-conditions  for  this  event,  no  assertions  are  entered  in  the  data  base 
for  the  initial  situation. 


in  S : amply 

The  let  statement  declares  and  initializes  a variable  quauaat  with  an  empty  sequence  NS. 
The  following  assertions  are  entered. 

queuees 

***  ^InilliliMd-quiuiN  * 

(quauaat  hat-eontentt  NS) 

(NS  is-o  ( SEQUENCE  )) 


Then  in  this  situation  an  actor  whose  script  (i.e.  code)  is  given  as  the  (cases...)  statement  after 
(th*-queu«*itself  a ...  is  newly  created  and  returned.  This  actor  is  denoted  by  the-queue-itself. 
Furthermore  by  looking  for  free  names  (variables  or  identifiers)  in  the  script  of 


**  4h» 

tha-quaua-ilsalf,  its  acquaintances  are 
th*-qu«u**iU«ll.  To  record  this,  the 

found:  in  this  case  the  acquaintances  are  qu*u**t  and 
following  assertions  are  entered  in  the  next  situation 

“v  K 

s 

pot loo 

! 

• 

' v -'V  ••  — ■"*— 

v 

a,  ■ - ■ 
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(tha-quau«*its«ll  knowt-nhoui  tha-quaua-itsalf) 


The  contract  for  the  creation  requires  that  the  returned  actor  Q be  newly  created  and  have 
the  property  (Q  i»-n  (IMPURE-QUEUE  )).  Since  the  returned  actor  is  tha-quaua-ilsalf.  what 
has  to  be  shown  is  that  (tha-queua-ilsalf  i*-n  (IMPURE-QUEUE  ))  holds.  This  assertion  is 
translated  using  the  assertions  in  wfcrrr-clause  in  the  invariant  statement.  Now  it  has  to  be 
shown  that  the  following  assertions  hold  in  s,01t.erM,)0B-  (Note  that  the  assertions  in  the 
icAere-clause  are  instantiated  by  substituting  an  empty  sequence  []  for  fa.) 

(the-quau«-its«ll  knowx-nhout  queuovs) 

(tha-quaua-itsalf  knowt-nbout  tha-quaua-ilsalf) 

(qutuMS  hax-content*  S)* 

IS  •«-«.  ( SEQUENCE  ))* 

The  first  two  assertions  hold  in  S because  they  are  entered  in  S . 

poit-crol  ion  ' pocl-crtat  Ion 

The  two  assertions  entered  in  S, 

initial  i zo>i-qu*u*»i 

(quaueat  hnx-rnntrntx  NS)  and  (NS  ix-n  (SEQUENCE  )) 

can  be  inherited  to  Spol,_CP„,  jon  by  the  trans-situational  rules  for  types  of  assertions 
(<variabl«>  Eax-coniem*...))  and  (<actor>  it-a  I SEQUENCE...))  and  they  are  matched  against  the 
assertions  marked  with  *.  Therefore  it  is  concluded  that  the  returned  actor  tha-quaua-itsalf 
has  the  correct  internal  structure  prescribed  by  the  invariant  statement.  So  the  result  of 
(craata-impura-quaua  <*  [])  satisfies  its  specification. 

II.  Establishing  the  ENQUEUING  specification 

From  the  instantiation  of  the  specification  for  enqueueing: 

(event:  (th*-qu«u**its*lf  <=  (mj:  A)) 

(pre-condition*:  (tha-quaua-itsalf  i*-n  (IMPURE-QUEUE  !«))  ) 

(return*:  tho-queue-itsell) 

(poxt -condition*:  (lhe-qupup-ils«lf  i*-n  (IMPURE-QUEUE  !x  A))  ) 

which  is  obtained  by  substituting  lh«-qu»u»-ils«lf  for  Q in  the  contract  for 
(IMPURE-QUEUE...)  in  Figure  4,  it  is  assumed  that 
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(tha-quaua-itself  U-a  [IMPURE-QUEUE  !*)) 


holds  In  the  initial  situation.  By  the  invariant  statement  in  the  code,  this  assumption  is 
translated  into  the  following  four  assertions  (Note  that  x is  substituted  for  a In  the 
invariant  statement.)  the-queua-i  tsel  f 


nq-or-dq-ini t 1*1  \ / 

(tha-quaua-itself  known-nbnut  queuoesr — ' 
(the-queue-itself  knowt-ahoul  the-queue-ilself) 
(quauaas  ha.t-eonlrnlt  S)) 

(S  U-a  ( SEQUENCE  !x)) 


Now  the  message  [nr/:  A)  is  sent  to  tha-quaue-ilself.  The  message  sent  to  the-queue-ilself 
matches  the  first  clause  of  the  case  statement.  So  the  binding  of  A to  new-element  takes 
place.  > — aj  the-qu&ue-i  tsel  f A 


^rqcq  I v»d-nq  * 


(naw-alamanl  3 A) 


j x 1 | - | x2  •*'  [xn  | 


Then  the  value  of  quauaas  is  updated  by  a newly  created  sequence-actor  NS  with  its  elements 
[■quauaas  naw-alamanl].  Since  the  value  of  quauaas  in  ^rtc#ivt^.nq  *s  a sequence-actor  S. 
•quauaas  is  the  result  of  the  unpack  operation  on  S.  which  is  *x.  So  the  new  sequence-actor 
NS  is  represented  as  ( SEQUENCE  !x  A).  For  the  assignment  of  NS  to  quauaas,  the  new 
assertion  (quauaas  ha*-conieni$  NS)  is  entered  in  the  data  base.  So  the  following  assertions 

hold  in  the  next  situation. the=qu&’ie-i  tsel  f 

I I 1 queuees 


*n  upd*tid-ququqqi-nq  * 


(quauaas  kan-eonirnli  NS) 
(NS  U-a  [SEQUENCE  !x  A)) 


sT 


In  this  situation  tha-quaua-i»sal»  is  returned  Note  that  the  specification  for  the  enqueueing 
requires  that  lha-quaua-itsalf  is  returned  and  that 

(lha-quaua-ilsalf  U-a  [IMPURE-QUEUE  !x  A)) 


t 
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By  making  all  assertions  holding  in  Sup<JMtd  qu#u#sg  nq  explicit  by  applying  the 

trans-situational  rules  for  (<actorl>  knnwt-nbout  <actor2>)  and  (<identifi«r>  a <actor>),  the 
following  assertions  are  obtained. 


(queuaes  haa-eontrntt  NS)* 

(NS  is-«  {SEQUENCE  Jx  A))* 

(naw-alamant  s A) 

(tha-quaua-itself  knnw%-ahout  quaueas)* 

(Iha-quaua-itsaH  knotrt-nbou I tha~quaua-itsa1f)* 

(S  i»-a  {SEQUENCE  It))  < — S is  no  longer  rejerenced. 

It  is  easy  to  see  that  the  assertions  obtained  by  translating 
(tha-quaua*itsalf  i*-o  {IMPURE-QUEUE  *x  A))  through  the  invariant  statement  are  matched 
against  the  above  assertions  marked  with  *.  So  enqueuing  satisfies  its  specification. 

Besides  the  fact  that  the  implementation  of  enqueuing  meets  its  specification,  a very 
interesting  fact  is  revealed  by  the  above  symbolic  evaluation.  The  sequence  S is  created  by 
this  implementation  and  never  passed  out.  S was  initially  the  value  of  the  variable  quauaas 
•n  ^*r>q-or-dq-initi»i  ^ut  'n  ^*up<ut«d-qu»u»»*-nq  *s  not  ^ va*ue  and  there  are  no 

acquaintances  of  tha-quaua-itsalf  which  know  about  it  in  Supd#ud  qu.„,„  nq-  So  S is  just 
floating  in  the  air.  Thus  there  will  be  no  chance  for  S to  be  used  later.  S is  subject  to  the 
garbage  collection  In  this  implementation  every  time  enqueuing  takes  place,  a garbage 
i sequence  is  produced. 
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III.  Establishing  the  DEQUEUING  specification 

As  is  indicated  in  the  instantiation  of  the  specification  of  the  dequeuing: 

(event:  (tha-quaua-itsalf  <=  (rf<j  j) 

(ease-1: 

{/ire-condition*:  (tha-quaua-itsalf  is-n  {I M PURE-QUF.UF.  ))  ) 

(returns:  (ertinuWerf:)  ) 

{l>ou-rowUiionr.  (tha-quaua-itsalf  is-n  {IMPURE-QUEUE  ))  ) ) 

(r«»r-J: 

{prr-rondition*:  (tha-quaua-itsalf  is-n  (/ M PURE -QUEUE  B !y))  ) 

(returns:  (neti:  B (rest:  tha-quaua-itsalf))  ) 

{pou-rottdiiiont:  (tha-quaua-itsalf  is-n  {I M PURE-QUF.UF.  *y ))  ) 

which  is  obtained  by  substituting  tha-quaua-itsalf  for  Q in  the  contract  for  impure  queues  in 
Figure  4.  there  are  two  cases  needed  to  be  considered:  case  I)  where  the  queue  is  empty,  and 
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case  2)  where  the  queue  is  not  empty. 

Case  I:  (thc-quMM-itself ««-«  {IMPURE-QUEUE  )) 


Assuming  that  (Ihd-qusue-ilsdll  it-a  ( IMPURE-QUEUE  ))  holds  in  the  initial 
situation,  the  following  assertions  are  obtained  through  the  invariant  statement  and  entered 
in  the  data  base. 


Ill  ^ j ...  ,2 

nq-or-dq-ml  1 1 1 1 

(tbd-queue-itself  knawt-abnul  queuoes) 

(th*-qu«u«-itsell  knouit-aboul  th**qu«ue-ils«lf) 

(quauees  hat-eontrnit  $) 

(S  it-a  ( SEQUENCE  )) 

Now  the  {dq:)  message  is  sent  to  th*-qu*u*-ils«lf.  Then  the  message  matches  against  the 
second  clause  in  the  (cases...)  statement  and  S . is  reached.  Since  the  value  of 

rtcflivio-dq 

queuees  is  S which  is  an  empty  sequence,  the  first  (=>...)  clause  in  the  rules  statement  is 
matched  and  the  situation  S is  reached. 

••pty-ququqq* 

Then  the  {exhautted:)  message  is  returned.  At  this  point  the  contract  requires  that 
(the-queue-itself  it-a  { IMPURE-QUEUE  ))  holds.  Again  by  the  invariant  statement,  the 
following  assertions  are  required  to  hold. 


(tha-quaue-itsalf  knotrt-aboul  quauoas) 

(Ihe-queue-itsalf  knnwt-ahnut  th«-qu*ue*ils«lf) 

(quautas  hat-ronirnlt  S) 

(S  it-a  {SEQUENCE  )) 

The  above  assertions  are  matched  against  the  ones  which  hold  in  S . , . and  no 

° nq-or-dq-inl t IAI 

events  which  affect  the  conservation  of  validity  of  the  assertions  in  S 

' nq-or-dq- in  I » 1 1 1 

happened  between  and  SnQ_or  So  what  the  contract  requires  is 

satisfied  for  Case  I. 

Case  2:  (th*-qu«u*-its«lf  it-a  {IMPURE-QUEUE  B fy)) 

For  this  case,  (the-queue-itself  i»-a  {I M PU RE-QUEUE  B !y))  is  assumed  in  the 
contract  and  so  the  assertions  translated  by  the  invariant  statement  are  as  follows. 
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) the-queue- itself 


queuees 


nq-or-dq-ini  I nl 

(the-queue-itself  knowt-aboul  queuees) 
(the-queue-itself  knotrs-nbout  the-queue-itself) 
(queuees  hnn-content .«  S) 

(S  is-a  (SEQUENCE  B !y)) 


H 0 


The  message  is  sent  to  the-queue-itself  and  the  situation  ^ is  reached. 

The  value  of  queuees  which  is  S matches  the  pattern  [=front  !=rest],  because 
(S  it-a  (SEQUENCE  B !y))  holds.  By  this  matching  a new  sequence,  say  NS,  whose  elements 
are  !y  is  created  and  bound  to  rest  and  B is  bound  to  front.  So  the  binding  information  is 
also  added  in  the  next  situation. 

the-queue- i tsel f 


non-#»p ly-qu«u«»J  \ 

(front  = B) 

(rest  = NS) 

(NS  u-a  (SEQUENCE  !y)) 


After  queuees  is  assigned  the  value  NS.  the  following  assertion  is  entered  in  the  next 
situation.  /-A. _the-queue-i  tsel  f 


queuees 


updated -queue** -dq  " ^ 

(queuees  hai-contmii  NS) 


N> ^ 


£ 

Li] 


Now  in  this  situation  all  assertions  which  can  be  inherited  from  the  previous  situations  by 
the  appropriate  trans-situational  rules  are  as  follows: 


, . ....  /•-»  therqueue- 1 tsel  f 

(queuees  /»n*-ronieni»  NS)*  queuees 

(front  s B)  \ /*| j X < 

(rest  = NS)  / I 1 

(NS  i*-n  (SEQUENCE  »y»*  ~~  ^ 

(the-queue-itself  fcrt<  « about  queuoes)*  r — ■. 

(the-queue-itself  knou-t-aboul  the-queue-itself)*  ; B [ 

(S  i»-n  (SEQUENCE  B !y))  <—  S is  no  longer  referenced  !! 
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In  this  situation  (next:  B (rest:  Ihe-queue-itself))  is  returned  The  four  assertions  marked 
with  * guarantee  that  (Ihe-queue-itself  iVn  { IMPURE-QUEUE  !y))  holds  through  the 
invariant  statement  So  all  cases  are  shown. 

As  in  the  case  of  the  enqueuing,  it  is  also  revealed  by  the  symbolic  evaluation  that 
a sequence  S which  was  the  Initial  value  of  queuees  becomes  a garbage  sequence  at  the  end 
of  the  dequeuing. 


IV.  Establishing  the  TR ANS-SITUATIONAL  RULE 

for  (the-queue-itseif  iVo  {IMPURE-QUEUE  ...)) 

The  instantiation  of  the  trans-situational  rule: 

(for-atxcrtion:  (Iho-queua-itself  ij-b  {I  M PUR  E-QUEUE...)) 

{only-affrcting-cvcnlu-nrc: 

{(the-queue-itself  <=  (nq:...))  (the-queue-itself  <=  Idq:)))  )) 

which  is  obtained  by  substituting  the-queue-itself  for  Q in  the  (/or-av«rriion:..  )-c1ause  in  the 
contract  for  impure  queues  in  Figure  4 says  that  the  only  events  which  may  destroy  the 
conservation  of  validity  of  assertions  of  the  form  (the-queue-itself  i*-a  {IMPURE-QUEUE...)) 
are  (the-queue-itself  <-  (n 7:...))  and  (lha-quaue-ilsalf  <=  (rfq.)). 

This  is  established  by  the  following  facts 

1)  The  preceding  symbolic  evaluation  has  shown  that  »he-queua-itsal»  always  maintains  the 
invariant  or  integrity  conditions  before  and  after  each  invocation  by  (nq:...)  and  (rfq.) 
because  the  following  facts  are  shown  by  the  symbolic  evaluation. 

a)  immediately  after  the  creation  of  Ihe-queue-itself,  it  maintains  the  invariant  condition: 
(the-queue-itsell  is-a  {IMPURE-QUEUE.  .))  and 

b)  if  the  invariant  condition  is  satisfied  before  invocations  by  (nq:...)  or  (rfq:), 
th#-qu«u«-its»lf  still  maintains  its  invariant  condition  after  the  invocations. 

2)  The  preceding  symbolic  evaluation  has  shown  that  no  internal  constituents  of 
the-queua-its«lf  are  released  outside.  Note  that  there  is  no  way  of  releasing  the  cell-actor 
with  which  the  variable  queuecs  is  implemented,  (cf.  Section  9) 

3)  Ihe-queue-itself  accepts  only  messages  of  the  forms  (nq:...)  and  (rfq.)  and  the  state  of 
Ihe-queue-itself  expressed  by  the  conceptual  representation  {IMPURE-QUEUE  .)  can  be 
changed  only  by  events  of  the  form: 

(Ihe-queue-ilself  <s  (nq;...))  and  (Ihe-queue-itself  <=  (rfq;)). 
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Since  the  four  clauses  in  the  contract  for  impure  queues  have  been  established,  it 
follows  that  the  implementation  of  impure  queues  in  Figure  II  (or  Figure  13)  satisfies  the 
contract  for  impure  queues  in  Figure  4. 

13.  CONCLUSIONS 


The  work  presented  in  this  paper  is  based  upon  two  main  ideas  conceptual 
representations  and  the  explicit  use  of  situations. 

Conceptual  representations  serve  as  a notational  devise  to  describe  not  only  states 
of  individual  data  structures,  but  also  how  individual  data  structures  are  interrelated  at 
various  levels.  Since  conceptual  representations  are  able  to  directly  express  states  of  data 
structures,  specifications  of  data  structures  by  conceptual  representations  are  often  easier  to 
write  and  understand  than  algebraic  specifications.  By  separating  the  state  of  an  object 
from  its  identity,  conceptual  representations  can  describe  sharing  structures  of  data  and  can 
easily  specify  the  behaviors  of  data  structures  with  side-effects 

We  introduced  a notion  of  situations  which  was  the  state  of  a system  at  a given 
moment.  By  relativizing  states  of  objects  in  the  system  with  situational  tags,  relations  and 
assertions  about  states  of  objects  in  different  situations  can  be  expressed.  Our  assertion 
language  can  describe  systems  from  various  points  of  view  and  emphasis  by  appropriate 
choices  of  conceptual  represen'ations  and  situations  Thus  the  expressive  power  of  our 
formalism  is  strong  enough  to  cover  a wide  range  of  the  statements  which  are  needed  in 
debugging,  question-answering,  and  the  evolutional  developments  of  programs 

The  traditional  approach  of  progiam  verification  is  that  given  a set  of  assertions 
holding  in  a situation,  verification  conditions  are  generated  either  in  backward 
direction[Hoare  1968,  Dijkstra  1976]  or  in  forward  direction[F!oyd  1967]  In  contrast  to  the 
traditional  approach,  our  approach  is: 

First,  by  symbolically  evaluating  in  the  Jorward  direction,  a "partial"  description  of 
each  situation  in  terms  of  conceptual  representations  is  produced.  (Here  a "partial" 
description  is  used  in  two  senses:  I)  a description  of  a situation  at  a certain  level  of 
details,  and  2)  in  creating  a description  of  one  situation,  the  part  of  the  description  of  the 
previous  situation  which  has  not  changed  is  not  necessarily  duplicated  ) 

Then  for  answering  questions,  the  retrieval  is  performed  in  the  backward  direction 
using  trans-situational  rules 

Descriptions  of  situations  in  terms  of  conceptual  representations  enable  us  to  deal 
with  side-effects  and  working  in  both  forward,  ana  oackward  directions  allows  us  the 
flexibility  to  answer  questions. 
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APPENDIX  I DERIVATION  OF  AXIOM  »5  FROM  THE  CONTRACT  FOB  PURE  QUEUES 

Axiom  a5:  if  is-empty(q)  = false  A dequeue(q)  = <B,  q’> 

then  dequeue(enqueue(q,  A))  a <B,  enqueuelq’,  A)> 


is  derived  from  the  specification  of  queues  based  on  the  conceptual  representation  in  Section 
2.  In  the  following  derivation  c2,  e3,  e4,  c5,  and  c6  refer  to  the  lines  in  specification  base  on 


the  conceptual  representation. 

1)  ic-empty(q)  = false 

2)  dequeue(q)  = <B,  q’> 

3)  q < — > (QUEUE  B Jx) 

4)  q1  < — > (QUEUE  !x) 

5)  dequeue(enqueue(q,  A)) 

<-*->  dequeue(enqueue  {[QUEUE  B |x).  A)) 
= doquouo((QUEUE  B Jx  A)) 

= <B  , (QUEUE  !x  A)> 

= <B  , enqueue ( (QL' EU E !x),  A)> 

<— > <B  , enqueuefq',  A)>  q.e.d. 


; given  at  the  premite  of  the  axiom  a5). 
ifiven  at  the  premite  of  the  axiom  a5). 

ifrom  1).  2),  end  c6). 
ifrom  2),  3)  and  c4). 
;the  left  tide  of  the  axiom  a5). 

ifrom  3). 
ifrom  c2). 
ifrom  c4). 
ifrom  c2). 
ifrom  4). 


APPENOIX  II.  A CONTRACT  FOR  CELLS 


[conlracl-lor  (CEI.I.  ...)  s 

(event:  (create-cell  A) 

(returnt:  (new-aetor  C)  ) 

(poti-eonditiont:  (C  i*-«  ( CELL  A))  ) ) 

(event:  (C  <=  (contents?)) 

(pre-conditions:  (C  is-a  (CELL  B})  ) 

(returns:  B ) 

(post-conditions:  (C  i.«-«  (CELL  B))  ) ) 

(event:  (C  *•  D)) 

(pre-conditions:  (C  it-a  (CELL  E))  ) 

(returns:  C) 

(post-conditions:  (C  is-a  (CELL  D))  ) ) 

(for-assertion:  (C  is-a  (CELL  ...)) 

(only-affecting-events-are:  { (C  <=  (update:...))  } ))  ] 
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APPENDIX  III  ampty-ona-quaua-into-anothar  in  CLU 


ampty-ona-quaua-into-anothar  = 

proc(ql:  impura-quaua,  q2:  impura-quaua) 

return t rrcord[ampliad:  impura-quaua,  axtandad:  impura-quaua]; 
front-of-ql:  nity; 
daquauad-ql:  impura-quaua; 
front-of-ql,  daquauad-ql  :=  impura-queuatdq(ql) 

except  axhaustad:  return  {amptiod:  ql,  axtandad:  q2J  end 
impura-quauatnq(q2,  front-of-ql); 
ampty-ona-quaua-into-anothar(daquauad-ql,  q2); 
end  ampty-ona-quaua-into-anothar; 


APPENDIX  IV  impura-quaua  in  CLU 


impura-quaua  = clutter  it  craata,  nq,  dq; 

rap  sc  rreord[quauaas:  saquanca]; 
craata  = proc ()  rciurn«(cw); 

return  {quauaas:  saquancatcraataO); 
end  craata; 

X 

nq  = proc(a-quaua:  evt,  naw-alamant:  any)  rriurm(en); 

a-quaua.quauaas  :=  saquancataxtandh(a-quaua  quauaas,  naw-alamant); 
return  a-quaua; 
end  nq; 

X 

dq  e pror(a-quaua:  r.vt ) relurnt  (nny,  cm)  tignalt  axhaustad; 
if  saquancatampty(a-quaua.quauaas) 
then  tignnl  axhaustad; 
elte 

front:  any  :=  saquancatfirst(a-quaua  quauaas); 
a-quaua  quauaas  :=  saquancatrast  (a-quaua  quauaas); 
return  front,  a-quaua;  t multi-valuad  raturn 

end  dq; 

X 

end  impura-quaua; 


